Business Analyst Community & Resources | Modern Analyst

Three Audacious Goals for Business Analysts in 2013

Jarett Hailes — Wed, 02 Jan 2013 19:07:00 GMT

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals.

Merriam-Webster defines audacious as “intrepidly daring” and “marked by originality”. As the business analysis profession and Business Analyst community continue to mature, more organizations are seeing the value that professionally-executed business analysis can bring. Business Analysts have an opportunity to help organizational leaders achieve their vision for the future. Here are three audacious goals for 2013 to help Business Analysts capitalize on this opportunity.

1. Move Beyond Information Technology Solutions

Most Business Analysts are focused on the development of IT solutions to meet business needs. The ‘IT Business Analyst’ has been hailed as key cog in the overall IT delivery framework for organizations.

While information technology is one crucial supporting function every organization needs, it is not the only area where Business Analysts can deliver value. Technology is only effective if there people who know how to use it and processes that will ensure the overall business is able to perform tasks in an efficient and effective manner. Business Analysts need to ensure that all three of these aspects work together by identifying and assessing requirements for all components, not just the technology-related pieces.

Business Analysts can challenge the perception that their work solely fits into IT by demonstrating their ability to consider the process and people components during their prescribed activities. Go beyond writing system specifications and point out potential challenges that people will have with a complicated screen layout, or identify regulatory or policy issues that will impact certain functional requirements. Such actions will allow clients to see the need for a more holistic approach to solution development and can improve the high failure rates seen by projects that are ostensibly driven by IT. Even if you are working in a systems support role, you have the opportunity to present a more complete picture about proposed modifications that will allow everyone to realize how an application should be changed to meet the organization’s needs.

2. Master and Leverage Complementary Disciplines

As a Business Analyst you already rely on competencies and knowledge from other disciplines. Most business analysis knowledge areas use notions from areas such as systems analysis, project management and facilitation.

There are several disciplines that provide wonderful skills and techniques that Business Analysts can use to help accomplish their daily tasks more effectively. If you take the time to learn and master one or more of these disciplines, your value to your organization can increase exponentially. Not only do you improve your career options but you become a better Business Analyst by being able to deal with a greater breadth of problems.

Some of the disciplines that are worth mastering as a Business Analyst are:

· Change Management: understanding how people deal with change and how to help navigate organizations through change is a crucial set of skills in today’s environment. Business Analysts can leverage change management practices throughout their activities, most noticeably in stakeholder analysis, requirements management, requirements analysis and enterprise analysis.

· Mediation/Conflict Resolution: with change comes the possibility of interpersonal conflicts. People can disagree for a variety of rational and irrational reasons. Business Analysts are often at the forefront of such conflict while they attempt to define and manage requirements. Understanding how to assess a conflict’s root cause and having techniques to defuse volatile situations are crucial to help gain consensus and keep a project moving forward.

· Performance Measurement: Business Analysts can play an important role in reviewing existing solutions or working on the business case for change. Being able to define and implement relevant measures to evaluate individual solutions or an overall organization are key tools that are needed to help keep companies moving forward. Knowing how to leverage methodologies such as Lean and Six Sigma make doing these tasks that much easier.

3. Use Your Skills to Give Back

Many Business Analysts already volunteer their time to causes they believe in, but it may not be in a capacity that leverages their professional skills. Business Analysts can get a lot out of using their skills to give back to others, while at the same time helping their community. Not only is there the satisfaction of helping those in need, but an opportunity to learn how to take the experiences from such efforts and apply them in their organizations of employment. There are opportunities to help organizations who need Business Analysts as well as helping our fellow Business Analysts improve.

Here are some ideas on how to give back:

· Find a local non-profit or charity who could benefit from some business analysis but don’t have the in-house expertise or financial resources to perform the analysis.

· If you like to volunteer in developing countries, speak with the organization you work with to see if you can help them improve their operations or help them with a specific project that requires business analysis. We already have “Doctors without borders” and “Engineers without borders” – why not “Business Analysts without borders”?

· Pay it forward: mentor a less experienced Business Analyst so they can share their knowledge and expertise in the future with others.

· Start a community of practice with other BAs either inside or outside your organization to help improve everyone’s collective maturity and share ideas on how to perform BA activities better.

· Work with your local IIBA chapter to put on an event that will help the BA community grow.

What are your professional goals for 2013? Do you have any audacious goals?

Thoughts on the Agile Extension of the BABOK

Jarett Hailes — Thu, 01 Mar 2012 02:23:00 GMT

Today was the last day people could provide feedback to the IIBA’s Agile Extension of the BABOK. The most recent draft of the document was published in November 2011 for review and comment. The purpose of the extension is to provide readers an understanding of how business analysis can be performed within an Agile environment. Various Agile methodologies such as Scrum, XP and Kanban are presented in high level summaries, and then business analysis activities from the BABOK are mapped to the main events that occur in the general Agile environment. Finally, a list of techniques that can be applied to the BABOK activities in an Agile setting are presented.

Overall the document is well written and does a good job of describing how business analysis fits into an Agile setting. This is a topic that has been much discussed in the past few years, and two years ago I wrote an article that summarized several leading Agile experts’ views on how the Business Analyst role fits into the evolving Agile framework. As Agile methodologies continue to gain traction in corporate software development processes, it makes sense to ensure that Business Analysts feel comfortable with how their skills transition to a different environment.

That said I have a concern about having such an extension does to the perception of business analysis as a profession and to Business Analysts as a role. I do not see business analysis as some activity that is merely a component of software development or IT solution delivery. Business Analysts can play a strategic role in the organization to help ensure that the organization is capitalizing on its opportunities and adapts efficiently to changing market, regulatory and internal cultural changes. When BAs are deployed throughout an organization they can get a hands on sense of what’s working, what’s not, and can draw upon technical and behavioural expertise to find innovative ways to help the organization continually improve its operations. I have had the opportunity with several clients to step outside of IT departments and play such a role, and not only is it personally rewarding but it is also where I have been able to provide the most value.

In many organizations I come into contact with business analysis is perceived as some 'IT thing' done to 'help the techies figure out what the business wants'. This perception often comes found the originations of professional business analysis, and while understandable, it is something that must be challenged in order to unlock the potential of having professional Business Analysts throughout the organization working on problems that are not limited to an IT solution scope.

The second version of the BABOK made great strides towards demonstrating how business analysis can be performed outside of IT and explained why it is needed by organizations to adapt to today's constantly changing environments. While some organizations are starting to see the value of BAs outside of IT, having a document such as the Agile extension reinforces existing preconceptions of business analysis in a limited role. In some ways publishing an Agile extension seems like a mea culpa to the wider business audience, indicating that it is wrong to think of business analysis outside of a software development context. I am sure this is not the intention of the IIBA, but given the stage of development of the profession it may be an unintended consequence.

I have been meeting with several executives, managers of Business Analysts and consulting business development personnel in a study group of the BABOK. Through their reading and discussion of the BABOK’s concepts they have come to recognize the value of the information outside of an IT setting, which has taken some work given that while the BABOK V2 is more generic than before, many of the concepts and examples rely heavily on the IT domain. When I mentioned that there was now an Agile extension, most wondered if in fact we had all been reading too deeply into the BABOK; maybe it was just for IT environments after all.

Perhaps I am being too harsh on having such an extension – after all the Project Management Institute has a construction industry extension to the PMBOK, which is one of the industries that were a main influence in the beginning of the institute, as well as for government. The PMI even has an Agile practitioner certification, which is decidedly focused on software development. Nonetheless, I feel that given the developmental stage of business analysis as a profession, having such an extension sends mixed messages on the applicability of the body of knowledge, and limits the career opportunities for Business Analysts in the near term.

As I mentioned above I think the content is valuable and good for BAs who are working in the IT domain to know, but I believe that some other term may be been better suited to describing the document. Calling it an extension of the BABOK ties it too heavily to the general body of knowledge in my mind. I could have seen this as a valuable ‘industry application guide’ or something along those lines.

What are your thoughts on the Agile extension? Do you like the content? What do you think that such an extension does to the perception of business analysis in general and outside of the IT domain in particular?

10 Things I Wish Someone Had Told Me When I Was Starting Out As A BA

Howard Podeswa — Tue, 15 Feb 2011 05:32:00 GMT

I am no longer a Webinar virgin. Thanks to the good folks at the IIBA, this week I had my first Webinar experience as an interviewee as part of the IIBA’s ‘ABC’ (Authors, Books and Conversations) series. The host, Julian Sammy, was brilliant in being able to pick out the questions that would be the most difficult for me to answer. (I hear that’s what makes him a great BA, too.) Of course, afterwards, I was regretting not being able to do a ‘do-over’ – until I remembered that I could – sort of – thanks to my MA blog.

Julian’s toughest questions were about the 3-way connection I saw between psychology, business analysis and art; I’ll leave that for later. But there was a BA question that I didn’t have a ready answer for, “What are the most important things you wish you had known when you were starting out as a BA?” Maybe it’s because it’s been so long since I have been in that position. But the memories have begun to come back.

So, for Julian - and anyone else who might be interested: here, then, after some thought, is what I wished someone had told me when I was starting out:
1. See every BA engagement as an opportunity to learn about other people - and not just to learn about another system: I thought my success or failure as a BA would be all about my analysis skills. I have since found out it hinges more on my ability to connect with people from a wide variety of backgrounds and cultures.

2. Turn off the inner monologue while listening to other people. (See #1 above).

3. Find out, from day 1, who will have ultimate signing authority – then meet that person as soon as possible: I’ve had bad shocks early in my career when I found out that the one person I really needed to convince was the one person I didn’t know about - until it was too late. I now do everything in my power to bring that person into the process ASAP.

4. Don’t go off for too long on your own: In my earlier days, I would do a big round of interviews and then go off for a long period to produce a big ‘tome’ of documentation. I found out soon enough that it’s too much for stakeholders to absorb at once and it’s too easy to propagate mistakes – like too much or the wrong kind of documentation. Now I provide feedback frequently to stakeholders.

5. The only way to get a good user interface is through many iterations of prototyping and user testing – because most people don’t know what they want till they see it. The focus of the BA in this case is to find out what the flow of the interface should be from the user’s perspective (the ‘Basic Flow’ – in use-case parlance), as well as the alternative scenarios that need to be addressed, while the designer works to realize these flows in the prototypes.

6. Test assumptions as early as possible in order to mitigate risk – especially if this is something you (or your organization) is doing for the first time: I’ve personally worked on 2 major projects where untested assumptions about new technology resulted in long delays and lots of rework once they were found to be untrue - and I have direct knowledge of many more projects that have suffered the same fate. By testing assumptions early I am now able to reduce the impact of unexpected problems.

7. Budget your time wisely: In the early days, I blew too much analysis time on small parts of the business area. I am much more careful now in planning and budgeting my time. I’ve learned to work top-down; in the beginning, I concentrate on the big picture and work my down into the weeds as the project progresses.

8. There is almost always a hidden agenda: For any non-trivial project, there is bound to be some aspect of office politics that can make or break the project. In many cases I have ended up being an unwitting pawn in someone else’s power play. In one case, for example, there were warring departments, each of which had already made up its mind about the preferred solution; the hidden agenda of the project champion who brought me onboard was to get an ‘unbiased expert’ to recommend his preference.

9. Don’t solutionize the requirements: The requirements as written, should make sense regardless of the technology solution. Otherwise, they will not be reusable should the preferred solution change – leading to lost time and effort.

10. The clients already know the answer: This is the secret lesson of consulting that I learned at the hands of a colleague (Brian Lyons) – and I’ve found it to be true more often than not. In many cases (such as process improvement projects), the clients know what’s wrong and what they need to do about it - and are really looking to the BA to confirm what they already know, or to help them formulate their thoughts. Yet another reason why it’s more important to listen than to talk.

And what about that question about psychology, business analysis and art (all of which are interests of mine)? The flippant answer is to say that these interests co-exist but they don’t necessarily connect. By maybe they do. I have an endless curiosity about people and how they live their lives – and it is a curiosity that the BA profession has helped me satisfy. As well, I have always been interested in the structure of thought – a theme that underlies both cognitive psychology as well as structural analysis. My art similarly has two recurring themes - often concerned either with the psychology of an interaction (see this series based on my experiences in South Africa) or with the way the mind organizes information (see this link for work based on organizing visual bytes of information).

So maybe there is some connecting thread to it after all.

- Howard Podeswa

6 Traits Of A Great Business Analyst (And How To Interview For Them)

Jarett Hailes — Tue, 19 Oct 2010 02:16:00 GMT

Whether or not you have ever been a Business Analyst yourself, if you work with enough Business Analysts over time you learn what sort of characteristics make a BA successful. Regardless of the Business Analyst’s skills, experience, domain knowledge or certifications, there are inherent traits that will more often than not help a person succeed in accomplishing business analysis tasks.

Over the years I’ve come to recognize most, if not all, of these traits in individuals whom I and many others have recognized as great Business Analysts. These traits are valuable because they help one thrive in a role that often comes with no authority (but lots of responsibility), can have constantly shifting demands and priorities, a lot of environmental ambiguity, and yet is one that plays a key role in the success or failure of projects, initiatives, and even overall organizational performance.

These traits are not meant to determine whether a person is a competent Business Analyst. Competency in business analysis tasks is something that typically is tied to the ability for an individual to perform BA tasks at a certain level of complexity and autonomy. Usually Business Analysts improve their competency over time with experience and ongoing professional learning. That said I find these traits can partially predict a person’s inherent ability to rapidly improve their competency in business analysis through on-the-job and classroom training and experience.

The neat thing about these traits is that you can structure interview questions and scenarios to actually try and bring these traits to the surface. If you look for these traits while you’re interviewing you will definitely have a leg up in determining if the candidate will be able to work well as a BA in your organization. While you will still want to assess the BA based on their skills, experience, etc., I would highly recommend looking into setting up scenarios during your hiring process that will help you establish whether these traits are inherent in the individual or not. I’ve put some suggestions on how to search for these traits during interviews below.

1. They are engaging

Business Analysts need to do something that is inherently tricky; convince people to commit their time and effort to working on activities that often aren’t their top priority. Rarely does a BA have the project with stakeholders who can commit their full time to requirement elicitation and validation, or have an unlimited amount of time to follow the schedules and priorities of their stakeholders and have requirements gathered when it suits them. Business Analysts often learn how to cajole, coerce, beg and otherwise convince stakeholders to help them accomplish their tasks, but the process is a whole lot easier if the Business Analyst is engaging. A great Business Analyst makes you want to work with them, even if you’re the Director of Sales and they need you to help define performance metrics for the CRM database upgrade.

A Business Analyst that can communicate the value of a project with passion and dedication will inherently pull people in without needing to list off the million reasons you need to be involved. Instead, you’ll want to be involved (or at the very least be willing to be involved more than you otherwise would). Having an engaging Business Analyst can bring everyone to the table and help groups focus on achieving meaningful results in a short amount of time.

How to interview for this trait: Look for the most boring looking project or accomplishment on the candidate’s resume and ask them to describe to them how they were able to perform . Ask them a similar question for what looks to be an interesting or exciting project. Listen to how they deliver their responses. If you feel like you want to hear more from the candidate regardless of the project being discussed, then there’s a good chance that the BA knows how to be engaging regardless of the environment.

You can also ask them about how they’ve dealt with situations where stakeholders were not committing sufficient time/effort to accomplishing tasks and how they overcame it. If the first thing out of their mouth was “I talked to the Project Manager” then you probably have someone who does not believe they can inherently engage stakeholders.

2. They aren’t easily ruffled by conflict

Business Analysts are often faced with unruly or disagreeing stakeholders, unrealistic timelines and potential or actual shifts in scope. Sometimes all their hard work that has been put into gathering, validating and presenting requirements turns out to be completely useless as soon as the sponsor sees the report and says “but I thought we were supposed to build X. That’s what I really need, regardless of what the charter says”. Top that off with trying to get stakeholders to return your calls and e-mails, evaluate the relevancy of 200 business rules in the current software, and fighting with the new requirements management tool and it’s a surprise there aren’t more Business Analysts with frayed nerves.

Like Project Managers, I’ve found that great Business Analysts cannot be easily perturbed. They realize that most of their environment is out of their control, and even though they can often be held accountable for things beyond their scope they take as much as possible in stride. Business Analysts have to be able to handle constantly changing goals, priorities and whims of many stakeholders. While they shouldn’t be simply trying to accommodate everyone without question, they need to realize that it’s all part of the process and that inevitably there will be delays or issues that will impact deliverables and timelines.

How to interview for this trait: It is one thing to say “tell me a time when…,” it’s quite another to actually see someone’s reaction when faced with a situation. After a candidate has responded to a behaviour-based question, one of the interviewers can pretend to become rather rigid and start making assertions that the Business Analyst did not do the correct thing (e.g. “I don’t think you should ever contact the sponsor directly, you should always go through the Project Manager”). Have the interviewer continue to insist on their point as the candidate tries to explain their reasoning or position. Don’t get into any unprofessional conversations such as name calling, but be stubborn. If there’s a hint of a defensive response, then that’s a bad sign. If they take it in stride and are able to accept the interviewer’s opinion, then this is a very good indicator. Business Analysts should expect everyone to have an opinion different from them and know when to move the subject along and acknowledge the person’s point of view.

While I don’t think this technique is suitable for every interview process, I think it can yield insightful responses in many circumstances.

3. They are multi-disciplined

A lot of Business Analysts have expertise and experience in IT and their domain. While this could be considered multi-disciplined I am looking for individuals who have experience in performing tasks in completely unrelated fields across multiple industries. I find that Business Analysts are able to more easily relate to capture information, interact with stakeholders and identify opportunities if they’ve worked in many industries, either as a BA or in an operational role. Great Business Analysts can leverage their knowledge of several disciplines to take techniques and information and apply it to their current project or duties. I find Business Analysts who have been in several industries to be more versatile and less susceptible to believing that certain analysis tools, techniques or work products are what are needed for any and every situation. Business Analysts with an academic background that crosses several disciplines (for example, a degree in Sociology but a Master’s or Doctorate in Math) also demonstrates a multi-disciplined mindset and experience.

A great Business Analyst realizes that all their activities and methods need to be adapted to the specific environment and situation at hand. Multi-disciplined Business Analysts can often find innovative ways to deliver value to their projects and organizations with their wide range of knowledge.

How to interview for this trait: Few people stay in the same field for their entire career, so ask the candidate to discuss a time when they’ve applied knowledge from a job in one field and used it in another field (even if it’s what they learned flipping burgers before heading into investment banking). If the candidate has always been in the same field but has an education in a field that is more or less unrelated to business analysis (Arts, Chemistry, Real Estate, etc.), ask them how they feel that education can help them in a specific BA situation (e.g. “What did you learn with your that would help you be able to ensure that you have a complete set of requirements?”).

4. They are inquisitive

I’ve never met a great Business Analyst that didn’t ask more questions than they answered over the course of a project. Great Business Analysts realize that they are merely a conduit of information and are always asking as many stakeholders as needed to help elicit, refine, validate and implement requirements. A Business Analyst should always be thinking “What, why, how, where, when, who” when they’re communicating with stakeholders and analyzing solutions.

Often Business Analysts won’t get the real information they need the first time around. Whether it’s determining the root cause of a problem, identifying the core need, or ensuring that all the bases are covered when reviewing a potential solution, great Business Analysts realize that while they’ll probably never have a complete set of information they can ask timely and relevant questions to get as much information as possible so effective decisions can be made.

How to interview for this trait: Tell the candidate a little about the project or operational role they will be performing, but keep it high level. If they don’t ask any follow up questions, that’s a major red flag. The more questions and follow ups they ask that are pertinent and relevant, the more likely they are naturally inquisitive and know how to search for important details and considerations. (Note: if they start asking questions like “what’s my vacation pay” and “what are the benefits of the company” before asking for a lot of details about the role, you’re probably looking at the wrong person for your job).

5. They think (and action) strategically

Business Analysts need to always be asking questions about the value of their work. Work that doesn’t relate to the strategic goals of the organization doesn’t just have little value, it’s really fake work. Great Business Analysts understand why what they’re doing has value and can articulate that to stakeholders. In addition, they are always looking for ways to uncover value for the organization by thinking about the organization’s strategic goals. This may lead the BA to recommend the merger of two overlapping projects or highlight the opportunity for process re-engineering that will reduce costs. Great Business Analysts show their companies that they are not simply the “IT guys who don’t just talk tech,” but are people who understand the needs and goals of the organization and can find ways to help them realize their objectives more efficiently.

Great Business Analysts also know how to action on strategic thinking. Rarely will the Business Analyst have the authority to act on an opportunity themselves, but they are willing to develop compelling arguments for superiors to take action. Doing so may place them at a slightly higher level of risk (since they may be going against popular or conventional thinking), but they also do this altruistically for the greater good of the company. I’m not advocating that Business Analysts should be mavericks, but they should know how to communicate the value (or lack of value) in recommendations to superiors.

How to interview for this trait: Give the candidate a scenario for a proposed project. Ask them if they believe the project is a good one to undertake given your company’s goals (assuming the BA could have found these goals on your website or in provided materials prior to the interview). Good candidates for any position should review those goals prior to going to a job interview, and a great Business Analyst should know how to measure a project against those goals.

Also ask the candidate if they’ve ever been on a project where they didn’t think the project was that valuable to the company. Start off by asking them something about the project (how was it run, how did they know it wasn’t valuable, etc.). After they’ve done describing the project, ask them what they did to let others know that the project wasn’t valuable. If they didn’t do anything or very little, then this makes me question whether they can really action on strategic thinking.

6. They care about the details

Most of the above traits are things you want to see in other roles, particularly business leaders and salespeople. One of the things in my mind that sets the Business Analyst role apart from some of these other roles is the need for attention to detail. You can’t be an Analyst without being a little bit anal J Great Business Analysts know the importance of having precise and clear details documented and communicated properly, and are adept at managing large amounts of detailed information.

This also means that a Business Analyst must be able to scale their message and thought processes. A great Business Analyst can give a compelling presentation to executives on the value of a project and then turn around and discuss with a Quality Assurance member why a change to requirement R-1938 impacts test cases T-321 and 329. Without proper attention to detail the Business Analyst can’t ensure that the actual solutions developed or procured will meet the needs of the customer, or even that those needs are sufficiently articulated to be able to adopt solutions.

How to interview for this trait: The best indicator of this trait is to review work products that were exclusively developed by the candidate, although this is often difficult to acquire. Instead you can get the candidate to play the equivalent of Where’s Waldo. Ask the candidate to review a sample deliverable and point out potential issues in the content (e.g. imprecise/ambiguous verbiage in requirements, lack of traceability, etc.). Make sure you give them sufficient time to review the document; this is typically a good activity for a 2^nd or 3^rd interview. The more issues that the candidate uncovers the better (bonus points if they spot stuff you didn’t even intend to be an issue).

I would also evaluate how detailed the candidate’s questions are when asking about the job, the work environment, etc. Again great Business Analysts want as much information as possible, particularly when they’re looking to commit to a position that will take up the majority of their waking hours.

Finding Great Business Analysts

Finding great Business Analysts can take time and effort; hopefully these traits will help you identify individuals with the potential to be great BAs even if they’re in different roles or don’t have the experience yet.

What are some traits of great Business Analysts that you have worked with?

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Intermediate Business Analyst Certification Brings Hope for the Junior Business Analyst: CCBA

Chris Adams — Sat, 02 Oct 2010 23:52:00 GMT

The International Institute of Business Analysis (IIBA) has recently announced a new intermediate business analyst certification called the Certification of Competency in Business Analysis (CCBA). The CCBA is being offered by the IIBA as an intermediate business analyst certification for a more junior business analyst who may not meet the more stringent requirements associated with the CBAP.

Timelines for the Certification of Competency in Business Analysis (CCBA)

A junior business analyst will be able to apply to take the Certification of Competency in Business Analysis (CCBA) starting in late 2010. Then in early 2011, a junior business analyst will be able to sit for the exam.

The IIBAs Vision for the Certification of Competency in Business Analysis (CCBA)

For some time now the business analysis community has been voicing the need for an intermediate business analyst certification. In response, the IIBA has developed the Certification of Competency in Business Analysis (CCBA). The IIBA views the CCBA as a stepping stone to the CBAP designation. The CCBA provides recognition for individuals who have business analysis experience and can demonstrate a clear proficiency in business analysis, but don't yet meet the requirements for the more rigorous CBAP designation.

Since the Certification of Competency is Business Analysis (CCBA) is truly intended to be a stepping stone for a junior business analyst to the CBAP designation, the CCBA designation expires after five years. The IIBA anticipates that the CCBA recipient will want to obtain their CBAP designation before the CCBA expires. If this doesn’t happen the recipient of the CCBA does have the opportunity to rewrite the CCBA exam.

Benefits of the Certification of Competency in Business Analysis (CCBA)

The Certification of Competency in Business Analysis can provide a number of benefits to a junior business analyst.

The CCBA designation acknowledges a junior business analyst who has invested in his/her BA career and has obtained a certain level of proficiency in business analysis.
An intermediate business analyst certification like the CCBA can increase the market opportunities available to the junior business analyst.
Preparing for the CCBA can improve overall knowledge and performance as a junior business analyst.

Employers also can benefits from having a junior business analyst receive the Certification of Competency in Business Analysis designation.

Demonstrates within your organization that your team values industry standards and professional certifications.
Provides advancement and recognition opportunities for your staff throughout the rest of the organization.
The CCBA demonstrates to your customers, competitors, and suppliers that you have qualified staff working on your projects.

Application Requirements for the Certification of Competency in Business Analysis (CCBA)

While the IIBA has made the requirements for this intermediate business analyst certification easier to obtain for the junior business analyst, there are still some sizable hurdles to overcome. Each of the following application requirements for the Certification must be met at the time of applying to be approved to sit for the exam.

Minimum 3750 hours of BA work in the last seven years, which is about 2 years of experience doing business analysis work. So this aligns well with the junior business analyst role.
Minimum 900 hours in 2 of the 6 knowledge areas or 500 hours in 4 of the 6 knowledge areas.
Minimum 21 hours of professional development (see the list of IIBA endorsed education providers)
Minimum high school education or equivalent
Two references from
- a career manager
- a client, or
- a CBAP recipient
Signed Code of Conduct

While the application won’t be available until the end of 2010, it probably wouldn’t hurt to know what the CBAP application looks like as they will probably be very similar.

How the Certification of Competency in Business Analysis (CCBA) Breaks Down

Since both the junior business analyst and senior business analyst roles tend to perform the same tasks (the difference is typically in the level of complexity of their work), the Certification of Competency in Business Analysis (CCBA) exam questions break down similarly across the 6 BABOK knowledge areas (v2.0).

Business Analysis Planning & Monitoring	20%
Elicitation	13.33%
Requirements Management and Communication	16%
Enterprise Analysis	15.33%
Requirements Analysis	19.33%
Solution Assessment & Validation	16%

How much does the Certification of Competency in Business Analysis (CCBA) cost?

If you’re planning to sit for the CCBA, be prepared to spend a little bit of money. The application fee alone is $125 USD. Then the exam fee is another $325 USD for IIBA members and $450 USD for non-members.

The annual membership fee for The IIBA is $95 USD. Since members save $125 USD on their exam fees the choice is clear, become a member for $95 USD and save money.

Business Analysis Conference Europe 2010

Adrian M. — Sun, 08 Aug 2010 06:36:00 GMT

The Business Analysis Conference Europe 2010 is building on its highly successful inaugural conference with more workshops and a third track – Business Agility and Business Analysis. It brings together business analysis specialists from across Europe and beyond, providing a platform for promoting the BA profession and opportunities for BAs’ professional development.

The conference runs from 28th to 30th September 2010.

This year we have partnered with the IIBA UK to run an online pre Conference series. Conference speakers will be providing articles to give a real insight into the benefits of attending the Business Analysis Conference in Europe.

One of the keynote speakers, John Seddon, has contributed a piece on the Systems approach to the design and management of service organisations.
The Telegraph described John as a 'reluctant management guru', a description John accepts as his interest is in changing management thinking.

(John Seddon’s key note Conference contribution is described here)

Ellen Gottesdiener and Allan Kelly who are recognized experts on Agile, will share their views on business analysis and Agile from both sides of the pond.

(Ellen Gottesdiener’s Conference contribution is described here)
(Allan Kelly’s Conference contribution is described here)

Joe Da Silva is an experienced business analyst for Skandia who will explore the diverse roles a business analyst can play. (His conference presentation explores his experience in Enterprise Analysis when his organisation recognized the benefits of using internal business analysts instead of expensive, external consultants).

(Joe Da Silva’s Conference contribution is described here)

These are just a few of the articles that are planned and there may be a webinar in the last couple of weeks prior to the conference.

Business analysis is now the central discipline for defining creative and agile options for business change and ensuring that solutions meet business needs. The Business Analysis Conference 2010 will provide an interactive forum where business analysts can learn and debate the essential competencies needed to rise to the challenges faced by their organisations today and in the future.

Read more about the Business Analysis Conference Europe 2010 here.

IMPORTANT DISCOUNTS:
There is a 10% discount available to IIBA members and 15% available to members of the UK Chapter. There is also a discount of up to 25% for group bookings.

Modern Analyst members and Business Analyst Mentor (www.bamentor.com) readers qualify for a 10% discount (Note: this cannot be combined with any other discounts).

When the Client Isn't the Customer

Jarett Hailes — Tue, 03 Aug 2010 00:09:00 GMT

Usually when a Business Analyst is working on a project the client (which I’ll define as the party or stakeholder who receives the benefit of the Analyst’s services) and the customer (the party who is paying for the Analyst to render the services) are one in the same, at least from an overall organizational perspective (i.e. the client and customer belong to the same organization). However, there are times when the client and customer are completely separate entities.

This sort of situation can arise in many environments. For instance, the customer may be an association who wants a new software solution that will be used by its members. Other times an entity may be required by law or regulation to provide certain services to other organizations and a project is struck to create a new solution to address these needs. Regardless of the circumstances, having a separate client from the customer can put the Business Analyst in compromising situations, typically due to divergent needs between the customer and the client.

Typically when a Business Analyst faces a situation where various project stakeholders have differing goals, agendas, capabilities or level of engagement in a project, the project’s structure can usually help resolve differences that can’t be worked out through other means. Within most project structures there will be a project sponsor or steering committee that is responsible for final decisions if consensus cannot be met. However, in a multi-organization project the project’s structure may have little to no representation from the client base. This may not be too surprising, particularly if the project was struck based on primarily internal consultations.

Often the Business Analyst is an advocate for those who will use the end result of the project. To become an advocate one needs to empathize with the client base or else it is difficult to communicate the client’s needs to the other project stakeholders. Once the Business Analyst understands the client’s needs they can often want to see those needs become fulfilled by the project.

However, the customer may not have the desire, resources or mandate to meet these needs. If the customer for whatever reason doesn’t believe that some or all of the client’s requirements need to be met and the project structure does not lend itself to providing the client a voice at the decision table, the Business Analyst may find themselves having a hard time accepting the customer’s position.

When the client and customer are not the same entity the Business Analyst ends up in a type of agency problem; they’ve become an agent for the client whose interests do not align for the principal (the customer). The Business Analyst was tasked with eliciting requirements for the client; if the customer in the end chooses to neglect some of these requirements it can be frustrating or disappointing to see the client’s needs going unmet.

Ultimately the Business Analyst will be faced with a choice to decide how far they will go in representing the client’s needs. Since the customer has the ultimate authority on the project the Business Analyst must determine what level of conflict is healthy to ensure that the client’s needs are being met to the best of the customer’s ability given the overall project environment. Obviously the Business Analyst should work within the bounds of professionalism, but there is a question at what point the Business Analyst should acquiesce to the customer’s expectations.

I don’t believe there is a simple solution or answer to this dilemma, and each Business Analyst will need to decide for themselves where the boundary lies if they encounter this situation. Have you ever been in a situation where your role as a Business Analyst put you in conflict with the project sponsors or Steering Committee? How did you deal with the situation?

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

The Lost Stakeholder Analysis Dimension: Engagement

Jarett Hailes — Fri, 19 Feb 2010 03:13:00 GMT

Stakeholder Analysis is an important and often ongoing activity that Business Analysts perform as part of their duties. Solution delivery team members need to understand who else is involved or impacted by their work effort, how they can interact with these people or groups, and what sort of tradeoffs exist in pleasing one group over another.

The BABOK highlights several important dimensions that can be collected on each stakeholder, namely:

The stakeholder’s attitude towards the project or solution team

The stakeholder’s influence on the project or solution team’s success

The type of stakeholder (internal/external, direct/indirect, etc.)

The body of knowledge also describes artifacts such as a RACI chart and stakeholder map to help manage the information you collect on stakeholders.

In addition to these dimensions, I believe that there is another consideration that needs to be included in stakeholder analysis: the stakeholder’s engagement level with the project or solution team.

A stakeholder’s engagement level describes the expected or actual amount of involvement a stakeholder has with the project. Since the required level of engagement with certain stakeholders may differ over the course of a project, this level should represent the level of engagement relating to activities that could or should involve the given stakeholder. In some cases, you may wish to separately track the expected/needed versus actual amount of engagement.

This is an important dimension to consider for several reasons:

The level of engagement that a stakeholder provides can greatly impact the amount of effort required to perform other Business Analysis activities, including requirements gathering/validation, solution assessment, enterprise analysis, etc.

If you expect to see high levels of active engagement from certain stakeholders who may not be considered high priority in the overall context of the project, you may find that the team will spend a disproportionate amount of time dealing with these stakeholders. By identifying such potential issues up front mitigation strategies can be developed to ensure that efforts are focused on where the highest needs are.

Conversely, if you identify high priority stakeholders with likely or actual low levels of engagement the team can identify potential solutions to address the causes of such disengagement, escalate this issue with the sponsor as needed, or allocate sufficient time to ensure that these stakeholders’ needs are still adequately met.

The Engagement Gradient

Every stakeholder’s level of engagement can vary. I use 4 markers as generic signposts to describe the general level of engagement each stakeholder has.

Proactive: these stakeholders are heavily involved in project activity. They are not only willing and able to answer questions, but they’ll ask you questions you haven’t thought about yet. They want to trial out potential solutions, volunteer for committees and the like. Generally they behave as an active team member rather than a stakeholder.

Responsive: these stakeholders get involved in the process, but only when prompted. They will respond to surveys, join in interviews or workshops, and provide suggestions to outstanding items but they won’t go out of their way to let you know something or volunteer to actively work on issues.

Marginal: these stakeholders will participate on occasion, but not all the time. They will provide limited feedback, give short responses, not really contribute meaningfully to discussions or suggest solutions to problems. Such stakeholders can quite often feel obligated to be involved (although if this is the case it should be documented separately in the attitude section).

Disengaged: these stakeholders you rarely or never hear from. They will not respond to meeting requests, surveys, etc. When they are present it’s virtually impossible to get them off their Blackberries or do anything beyond nod their head (either in agreement or disagreement).

You may find that some stakeholders exhibit various markers depending on the subject or issue at hand within a project. If appropriate you may have a matrix of engagement levels for your stakeholders with the stakeholders and the various aspects of your project representing the axes.

Leveraging Engagement in Stakeholder Analysis and Other Activities

By bringing in the engagement level dimension into your stakeholder analysis, you can now optimize your other Business Analysis activities much more efficiently. Taking this information into consideration in conjunction with the stakeholder’s attitude and influence towards the project can help identify potential risks to the success of the project, find potential bottlenecks in upcoming project activities and look for ways to improve stakeholder communications.

For example, let’s say that you have a stakeholder with a great attitude, is proactively engaged but of low influence to the project? Such a stakeholder could have the potential to take up a lot of the project’s time. Perhaps you can look to leverage their enthusiasm for the project by having them spread the word of the project, get other higher priority stakeholders on board, etc.

When a stakeholder is disengaged there could be several causes. If the stakeholder could pose a major influence on the project I try and determine whether the main reason is lack of time or lack of interest. If it’s the former then we can work on finding ways to involve them in more asynchronous activities or to get them involved at a higher level, if appropriate. If it’s the latter then I know the project may have a potential problem – perhaps the apparent value of the project is not there, or more work needs to be done to ensure this stakeholder sees the value and thus will contribute more to the project.

Looking at the overall engagement of all stakeholders can also give you an idea as to how well your engagement activities are being received. If it looks like most of your stakeholders are not very engaged with the project you may wish to review your communications plan as well as your other stakeholder activities and ask if you have had sufficient input in order to proceed.

It is important for a Business Analyst to acquire and deliver the right information from the right people and organizations within the course of their duties. Stakeholder analysis activities can help a BA navigate the sometimes challenging waters of ensuring that everyone has their voice heard and are sufficiently involved to ensure the project or solution is a success. Understanding the anticipated/desired and actual levels of engagement with stakeholders can help ensure that project goals are met.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Why I Don't Use BPMN

Jarett Hailes — Wed, 10 Feb 2010 01:59:00 GMT

First off, let me just say that I really like the BPMN standard, especially the 2.0 Beta specification. I find the notation to be a powerful and expressive language that takes into account not only the standard elements in business processes but also considers all sorts of interesting possibilities that may arise. I think the new Choreography and Conversation diagrams and additional event types open up new ways to describe intricate processes and collaborations between various individuals and organizations. Indeed, BPMN allows you to graphically model almost any situation that you can find in a business.

And I rarely get to use it.

According to the BPMN 2.0 Beta spec, there are two goals for BPMN. One goal “is to ensure that XML languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation.”

The other goal “is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.”

While BPMN does extremely well with respect to the first goal, I believe it does not live up to its second goal.

Business People Don’t Get BPMN Right Away

Whenever I stick a non-trivial BPMN model in front of actual business customers, I always get at least some questions. The number of questions varies depending on their sophistication and the number of times they’ve seen a BPMN (or similar) diagram before. BPMN leverages the typical flow-chart diagramming that nearly all business people are familiar with, but they’ve made several changes that make the their models anywhere from slightly confusing to downright unreadable for the layperson.

For instance, one of the most common questions I get is with respect to the fact that each pool has its own start and end processes as well as process flow lines. If there is interaction across the pools then a message flow is used. Most business people get overwhelmed with the additional flow lines and have trouble following the overall process path – usually when a hand off occurs between individuals or organizations you want to follow whoever received the handoff. With BPMN this is not always readily obvious since all pools continue along their own process flows. I could get around this by using only lanes instead of pools since lanes are not considered to be running their own processes, but then I’m not using lanes correctl. Each pool is defined as a “separate business entity or participant” while a lane is used to “separate the activities associated with a specific company function or role.”

BPMN Process Example

Other times people are thrown by the exceptions or compensation processes, since they are usually shown on the same page (although not necessarily). While I personally like these artifacts I often spend more time explaining why they are there than reviewing the accuracy of the actual process itself.

Over time I’ve been able to get some clients used to the notation, but if a new stakeholder is brought in I’m back at square one. To me this shows how BPMN is not ‘readily understandable’ by the vast majority of business people involved.

BPMN is a Great Precursor to BPEL

I definitely see how BPMN is an excellent tool to use if you’re preparing to leverage the Business Process Execution Language (BPEL) and have a BPEL Process Manager solution in place to automate business processes. The BPMN spec indicates that traditional models create “a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes.” BPMN has really been designed to address this gap, but has focused on the technical implementation side by sacrificing out of the box understandability for any given model.

From a solution standpoint this makes sense – if the goal is to in the end have automated business processes then you need to ensure that your model can translate into a language that is computer-ready. BPEL has been around for almost 8 years now and has gained a level of acceptance by software providers and businesses. Combined with the demand for lower labour costs wherever possible and there is clearly a need for non-programmers or extremely technical personnel to be able to leverage a graphical description of processes.

Like any other technically-driven language, BPMN is relatively generic, robust and flexible. In order to achieve its level of flexibility the language must be inherently complex to handle all the possible situations that could fall within the scope of the language’s use. While this is great from an implementation perspective it takes away from the ability for someone with little knowledge about the notation to be able to read a diagram.

When to Stick With the Tried and True Notation

In most situations (performing current state analysis, working through future state processes, validating requirements, etc.) that involve business people interacting with diagrams BPMN is a bit of overkill. When I’m not trying to create an automatable BPEL-driven business process I find that business people can almost universally understand a flowchart. This is something that most individuals have had exposure to at some point, and even if they haven’t there are so few different diagramming objects that it’s easy enough to pick up quickly (at the very least you don’t need a 226 page reference guide to figure out how to understand the chart)

While a flowchart may not be able to elegantly model complex business processes as well as BPMN, you can still get the job done by breaking up complex situations into several smaller component diagrams and then using the link object to move between the components. I find that this not only helps me ensure that each component chart is clear when I’m building the model, it also helps me work through specific sub-processes or exception cases with clients when I’m reviewing the details with them since it’s easier to focus on a single, relatively straightforward chart at a time.

Flowchart with Swimlanes Example

One part of BPMN that I’ve brought over to the flowchart world and use nearly every time is the swimlanes artifact. Having swimlanes helps everyone clearly understand the responsibilities and activities that each participant in the overall process plays, where the hand-offs are and what kind of information is going back and forth. I’ll often attach document or data elements when the flow goes across the lanes to show the details of the hand-off, which embeds a lot of the information you would typically find in a Data Flow Diagram (DFD) for the given business process. In fact, if you wanted you could roll up these messages and create a DFD if you have a need for that type of structured analysis.

While BPMN is a great way to prepare a business process for automation, it may not be the best choice when it comes to interacting with the business itself to document, verify and envision business processes.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Root Cause Analysis: Using the Five Whys

Jarett Hailes — Tue, 26 Jan 2010 00:55:00 GMT

Business Analysts are often thrown into projects to help gather requirements around a known, defined problem. Other times we’re asked to analyze the current state of a certain process, organization, system and look for ways to improve areas that are clearly lacking. I’ve noticed that when we are brought on a project, the problems described are likely only surface symptoms to large issues. For example:

· This system can’t handle more than X transactions per hour and it’s killing our procurement process’ performance

· This organizational unit doesn’t have the right staff to be able to keep up with the demands being placed on them

· This process is obsolete and overlaps with three of our other processes

While it’s great to have a problem identified, it is well worth the effort to ensure that you are analyzing a root cause problem and not only a symptom of a greater issue. If you don’t do this step, you may end up using lots of resources at what amounts to a band-aid solution.

A great technique to help delve into a problem and identify possible root causes is the ‘Five Whys’. When an issue is presented you ask the question ‘why did that issue occur?’ Once you have your answer, ask the question ‘and why is that so?’ Continue until you have asked ‘why?’ at least five times, even if you felt you’ve reached the root cause after 2 or 3 responses.

Joel Spolsky details a good example of how using the Five Whys can elicit solutions to underlying problems. Recently I came across a similar example with a client (certain details have been changed).

Issue: Employees did not receive their pay stubs on pay day.

· Why? Because the printing system failed the day before pay day.

· Why? Because the system could not recover from a hardware fault.

· Why? Because the system uses outdated hardware that has no automatic redundant backup.

· Why? Because the system hasn’t been replaced as it hasn’t been identified as a high enough priority to allocate budget to its replacement in the current economic climate.

· Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.

Some people may have been tempted to stop after the third or fourth question. We could have rushed to find a way to set up either an automatic failover system or to increase the availability of resources to replace legacy hardware in the event of a failure. Or we could have determined that the system needs to be replaced and develop a business case to do so. But the overall challenge that faces the organization is a way to assess the relative risks of failure for all enterprise applications and come up with mitigation strategies in light of the available funds to maintain and replace systems going forward and to holistically evaluate the replacement of such systems over time.

It may still be a good idea to address the symptoms found during this activity. In the end the root cause(s) that you identify may be deemed to be outside of the domain of you and/or your project team’s responsibility. The key is to recognize that there are potentially larger issues that may need to be addressed; otherwise this issue may resurface with different symptoms in the future and to pass along this information to those who can act on it.

The Five Whys isn’t the only tool you may want to use to help identify potential root causes (here are some suggestions on how to improve its efficacy at finding root causes), but I believe that it can be used to quickly assess whether a problem that has already been defined may in fact be a symptom of greater hidden issues.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Mitigating the Risk of Story Point Drift

Jarett Hailes — Mon, 18 Jan 2010 01:38:00 GMT

In many Agile projects requirements are not typically written in the form of a formal requirements document. Instead, a collection of concise but effective means of describing what must be built called user stories are often used. User stories describe the behaviour, performance, or interface of a system from a customer’s perspective. A typical user story might look something like this:

As a potential customer I want to be able to view books based on the search criteria I entered.

User stories are not only effective requirements management artifacts, they are also essential to estimate the scope/size of the project and to track the progress of the team. When determining the size of the project, teams estimate the level of effort required to complete each user story and then aggregate their results to come up with their estimate for the scope of the project (for more details on how to estimate level of effort in Agile projects, see Mike Cohn’s excellent book on the subject).

Agile teams will often use a unit-free type of measure called story points. The advantage of using story points is that their inherent value is relative. Instead of trying to come up with absolute values typically related to time (for instance, how many days will it take to complete feature X), story points are only concerned about the relative effort or complexity of a story compared to the other stories that have been or need to be completed. When the total number of story points for the project is combined with a team’s velocity (the number of story points completed per iteration period) project stakeholders are able to get an increasingly accurate picture of the size of the project and the time it will take to complete given the current team.

Initially when the team forms they will estimate story points for some number of baseline stories. For instance, the team may have the following 3 stories as their baseline:

As a user I want to browse the book collection by subject: 8 points

As a user I want to be able to save my payment information: 2 points

As a user I want to be able to recommend my favorite books to people: 5 points

From this baseline other user stories are estimated in terms of their perceived relative amount of effort to accomplish. For larger projects, most user stories are estimated as epics, larger user stories that will be broken down later on in order to actually tackle development.

Over time, new user stories will be added to the product backlog, others removed and some will be altered to reflect changing requirements. All the stories that are added or changed to the backlog will require story point estimation.

One of the potential risks that exists when using story points is what I call ‘story point drift’. Story point drift is when user stories that had a given story point value at the beginning of the project require substantially more or less effort than stories with the same story point value later on in the project for the given amount of effort required to complete a story.

For instance, let’s say I have the following user stories estimated later in the project:

As a user I want to be able to have my bank account linked to my login and set up a monthly withdrawal plan: 8 points

As a user I want to have a theme editor that can customize the look and feel of my online affiliate store: 5 points

While the above user stories may accurately represent their relative size compared to each other, in comparison to the stories that were estimated at the onset of the project it appears as though the latter group’s story points under-represent their complexity and level of effort required. I would suspect that the amount of work to enable automatic bank transactions is substantially larger than the amount of effort required to build a browse by subject feature.

I find the risk of story point drift increases on larger or longer-term Agile projects. Story point drift can occur for several reasons:

The team’s collective memory is short term: when a team begins estimating new stories, they typically draw upon their experiences from recently completed stories. If some of those stories were misclassified (either required materially more or less relative effort than was represented in the story point estimate), then the team can end up believing that these recent stories are the new norm for the value of the story points and use these as references going forward, which skew the story point values from the original baseline references.

The team’s complement has changed: it is not uncommon for project teams to change over time. I’ve noticed that even as teams get larger or smaller that a team’s velocity can appear to remain constant. When investigating this, I’ve found that it’s often because the team begins to estimate stories with fewer points, since they now feel that the story is ‘easier’ since there are more people to work on the project. As a result stories that might have been considered 8 points previously are now being estimated as 5 points. As a result, despite the fact that the team is likely getting more done given their drift in estimates the team’s velocity appears unchanged.

Baselines are not referred to: Agile projects usually thrive by the minimization of overhead that does not lead to customer value and by adapting to non-ideal situations. For example, Agile teams rarely wait for everyone to show up for a meeting – the meeting is time-boxed and starts and ends on time regardless of who is missing. However, at times Agile teams may forget to bring physical objects like their reference stories to meetings. Sometimes teams will try and get through the meeting based on recollection rather than actual reference. Without the actual reference stories and point values in hand, the resulting estimates can be somewhat skewed.

When I’ve seen story point drift it has occurred in small increments over time – you don’t realize that there’s been a dramatic deviation in the estimates until sometimes months later. Story point drift can cause issues with resource planning and progress and time to completion estimation. Here are a couple of strategies I’ve used to help mitigate story point drift:

Bring mixture of original and recent stories as the baseline for new estimation: it never hurts to hold up your original estimates when doing relative comparisons. Having some recent examples are also helpful, in particular since your initial estimates were likely only for a few potential story point values. Having 1 or 2 stories for each possible story point value can also be helpful when discussing what level of estimate to assign to a new story, or when individuals are deadlocked in a session of planning poker.

Know when certain stories should be re-estimated after implementation: once in awhile you will encounter a story that was a lot more (or less) effort than you initially thought. If the level of effort was sufficiently different from another story that was given the same amount of points, you may want to re-estimate the story so that it does not affect your team’s perception of the value of a certain number of story points. I typically would only re-estimate a story once a project has been going for several Sprints – early on you may discover that many of your stories take less or more effort than you thought and you’ll be tempted to resize those stories. However, as long as the stories are taking about the same amount of relative effort, then there’s no need to re-estimate. So if you thought your 3 point stories would take a day to complete but they’re taking the better part of a week, check to see how your 5 and 8 point stories are taking. If those are also taking a fair bit longer than anticipated, then don’t re-estimate.

Spend a little time every few Sprints and analyze relative stories: the ScrumMaster or Project Manager can review some of the completed stories over time to look for possible story point drift. If some drift is detected, bring it up with the team and see what they think. If the team agrees, then re-estimate the stories that appear to be out of what in terms of relative effort.

User stories and story points can be a very good way to manage the requirements and estimation for a project. Keeping an eye on story point drift will ensure that the team has a good handle on the project’s rate of progress and estimated time to completion. With diligence this method of project estimation can be a very accurate and effective tool for Agile teams.

-------

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Dispatches from the WCBA Conference: Jogging through the IIBA® BABOK®

Adrian M. — Tue, 17 Nov 2009 08:55:00 GMT

Here’s a dispatch from the first day at the World Congress for Business Analysts (WCBA).

I attended an all-day workshop titled “Get the Right Stuff, Fast: Jogging through the IIBA® BABOK® with the Requirements Roadmap” lead by Mary Gorman of EBG Consulting.

Mary is a Certified Business Analysis Professional™ (CBAP®) and works as Senior Associated for EBG Consulting, assisting teams to build the right products through exploring and confirming their requirements.

If Mary’s sessions was a jog, then this blog post will be a sprint – a very fast one, I might add!

The focus of the workshop was to:

Leverage the Requirements Roadmap to articulate requirements
Align requirements models to knowledge areas in the BABOK®
Create a set of interconnected requirements models to speed up the requirements development and successfully engage business users and customers.

During the session, Mary provided great insights on the business of “business analysis” specifically focusing on defining the scope of and modeling user requirements using the requirements roadmap:

You can get the PDF version of the requirements roadmap from EBG’s website.

During the session we raced (ok, just jogged) through the roadmap with pointers to sections in the various BABOK® knowledge areas:

Business Analysis Planning and Monitoring
Enterprise Analysis
Elicitation
Solution Assessment and Validation
Requirements Analysis
Requirements Management and Communication

Regardless of what methodology or techniques you use, Mary pointed out that it is important understand that we need to have a balanced perspective of the requirements through the lens of four fundamental model views:

Behavior: e.g. process, action, function, task, script
Structure: e.g. information, data, object
Dynamics: e.g. time, lifecycles
Control: e.g. business rules

The session slide included a nice Vann diagram of the four models with the control model being at the intersection of the behavior, structure, and dynamics models.

Jogging along… the session covered a number of techniques, including:

Stakeholder & Actors: Customer vs. User vs. Others => Ask: “Who?”

Glossary & Data Model: The building blocks for later constructs such as business rules => Ask: “What?”

Event-Response Tables: An effective tool to elicit user requirements => Ask: ”When?”

Use Case & Scenarios: Describe the flow of the actor-system interactions => Ask: “How?”

Business Policies & Business Rules: Statements that constrain some aspect of the business => Ask: “Why?”

The practical side of the workshop was the case study which forced everyone to roll-out their sleeves and put in practice the techniques discussed.

It was a cozy sessions with many chances for everybody to participate. Most of the session attendees got a free copy of the Software Requirements Memory Jogger.

- Adrian

Adrian Marchis
Publisher, ModernAnalyst.com

Art and IT: Two Solitudes?

Howard Podeswa — Fri, 10 Jul 2009 04:01:00 GMT

In these ‘tough economic times’ everything seems to be measured in dollar value and if that kind of value isn’t readily discernable, we often assume there is no other value either – or none that matters. It’s behind personal financial expert Suze Orman’s diatribe against teachers (who, according to Suze, can’t possibly have any self-respect if they’re willing to work for so little money), and behind a general devaluation of arts and culture - other than those aspects that have a proven monetary value. I think we’re missing something that the artists and scientists of the Renaissance period understood well, when an artist, poet, architect and scientist were not necessarily different individuals.

These thoughts came to mind as I was showing a copy of the new edition of my book, UML for the IT Business Analyst to a friend who is an artist. I pointed out the new painting on the cover, and he recognized it right away from a previous exhibition. But there the interest ended. Unsurprisingly, he had no idea what the diagrams inside meant - but he could not even entertain the idea that he might be able to understand them. It got me wondering why it so unusual for somebody who works in the arts today to have an aptitude or interest in ‘computers’ (by which I really mean software design and analysis, as opposed to, say, being able to use applications like Photoshop, which almost every visual artist knows how to use).

As in the arts – so in business: eyes roll when the subject turns to IT (Information Technology). Some people are just not that into it; but sometimes it’s just that they are intimidated by it - convinced from the outset that they’ll never get it. It’s a protection mechanism. (Either way, it’s something BAs need to be aware of. One practical implication, for example, is that the documentation that is presented to non-technical audiences should not lean too heavily on analysis diagrams: their association with IT is enough to damn them for many readers.)

In any case, I don’t mean to rag on my artist friends. The ‘2 solitudes’ argument cuts both ways. Few of my friends in the IT world are interested in art either: they don’t go to art shows, don’t buy art (posters don’t count); don’t look at paintings or ‘art’ photographs. The reasons, I think, are pretty much the same as for the artists who don’t do IT: not interested, or convinced they’d never get it. For the second group - those who are simply intimidated by art but want to know more, it helps to have a guide.

At the moment (and for the next week), I have a show of paintings up in a gallery. I’ve been taking people on ‘guided tours’ of the show – each time focusing on a different piece.

This blog is a virtual version of that – focusing on one of the paintings in the current show, ‘Colossus’.

The title refers to another painting by the same – ‘The Colossus”, attributed to Francesco Goya, a Spanish painter who painted it in the early 1800’s. Goya lived in a time of great upheaval and war – and this is reflected in his work. In the original painting, the Colossus is a giant man who towers in the sky above the human turbulence below.

My painting is not an attempt to redo the Goya; it’s more of a riff on it. In my version, the Colossus of the Goya has been replaced by … well, me. But I’m standing on solid ground, not striding across the sky. And I’m wearing Sorel winter boots. (Because this is Canada.) This is one of the first paintings I started while working on the show, but I finished it last. It’s a summing up of all that I’d done in series. Its subject is war and people on the move, the migrations we hear about every day in the news and the endless migrations that have preceded them. The people in the painting come from: a photograph, a painting of a village by the French artist, Eugene Boudin, and one or two Black paintings by Goya – a mixing of pasts and the present and timeless wanderings.

This remixing of disparate sources is something that art - the process of making it and looking at it - excels at: the ability to see, as in this case, that there is a way to make a connection between a contemporary photograph, an early French Impressionist painting and some very sombre Spanish depictions of the human condition in times of war.

Whereas science and technology are largely about following disciplined, repeatable processes to arrive at a result, art encourages the mind to wander between ideas and see unexpected relationships. It's a skill the Business Analyst needs to develop when looking, for example, for a common thread behind a slew of customer complaints or when coming up with a novel approach to solve a problem.

There's a bleed, in other words, between the ways of thinking promoted by art and those promoted by science. Which is why I think it's a good idea to explore both, as opposed to staying within one silo ... not that there's anything wrong with that.

And a couple more art links:

Howard Podeswa

P.S. After much work, the new edition of UML for the IT BA is now being printed. Many thanks to all those in the ModernAnalyst community who contributed their thoughts via this blog. While I wasn’t able to thank you all individually in the book, there is a big shout-out to the group in the book’s acknowledgements and, in particular, to Adrian Marchis, for establishing and supporting this vibrant community.

How much analysis do you really need to do?

Howard Podeswa — Sun, 03 May 2009 04:21:00 GMT

As a BA, one of the central guiding principles for me has always been, "If it isn't going to make a difference to the outcome, don't do it." Yet I see a lot of confusion amongst BAs about how much analysis to do on a given project. Are structural models (class diagrams and ERDs) always worth doing or are they a waste of time? How much detail should you put into the user requirements? Obviously, blindly creating documentation without understanding its value - or if it even has any value - is not useful. The problem is when to do what. I thought this would be the perfect forum to toss out the question: How much analysis do you really need to do? I invite all responses – pro and con, cool and heated.

My real aim here is to generate discussion, not to be proscriptive. To get the discussion started, I'll start with some general guidance I’ve found useful.

The degree of documentation and analysis required for a project depends on a number of factors, including the lifecycle approach being used on the project, the size of the project, the type of solution being contemplated (in-house or vendor solution), and the risk involved.

There are two broad categories of lifecycles used on projects: definitive lifecycles - which are well-defined processes – and empirical processes, which are less defined. Projects managed using definitive lifecycles will require more documentation; those using en empirical lifecycle will require less. For example, while in a definitive lifecycle you might produce complete user requirements – expressed, for example, as use-case specifications, with an empirical lifecycle this would be of little value, since the requirements are constantly in a state of flux. On the other hand, even on an empirical project, there is still a need to list (if not completely describe) user tasks (use-cases) early on so that the effort required for and cost of the project can be estimated.

With respect to size – the larger the project, the greater the need for documentation. The team is bigger, the problem is more complex and more dollars are at stake – all factors favouring heavy documentation.

Solution type is another important factor. In-house solutions favour more documentation; vendor-supplied off-the-shelf solutions favour less documentation. Business rules and requirements that are standard across an industry are more likely to be supported in an off-the-shelf solution – and, therefore represent less risk than requirements that are peculiar to a business area. Naturally, more effort and detail will go into documenting the high-risk requirements.

I’ve tried to summarize some of this in a table that looks at UML tool usage for projects based on their size, solution type and lifecycle approach. In the table, a ‘small’ project is one that has a short timeline and budget and does not involve a change to a business process; an example is a change to an existing screen, or the addition of a new query screen to an existing system. An example of a large project , on the other hand, is the introduction of a new business product or service. The notes in the last column of the table relate to new UML artifacts; however, where there are existing UML artifacts related to the problem, they should be reviewed, and amended as required. The table can be applied to non-UML projects simply by replacing the UML terms in the last column as follows:

‘Business process models’ – instead of ‘business use cases’
‘User requirements/ user tasks’ – instead of ‘system use cases’
‘Statechart diagrams ‘– instead of ‘state-machine diagrams’
‘Data models/ERDs ‘– instead of ‘class diagrams’

Tailoring UML tools usage to the project:

Project Size: Small

Solution type	Lifecycle	UML tools
In-house development	Empirical	Business use cases: May be skipped, as no changes made to business process. System Use Cases: List and name new use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be worked out through prototyping.[1] Class diagrams: Model new classes and relationships to discover structural business rules; may be skipped if problem well-understood. State-machine diagrams: May be skipped. Activity diagrams: May be skipped.
In-house development	Definitive	Business use cases: May be skipped, as no changes to business process.. System Use Cases: Complete Class diagrams: May be skipped if a simple change, such as query screen. However, if new business concepts introduced, model them and their relationships in order to discover structural business rules. State-machine diagrams: May be skipped Activity diagrams: Use as addendum for system use cases whose flows connect in complex ways.
Off-The-Shelf	All lifecycles	Business use cases: May be skipped, as no changes to business process. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will differ based on the vendor. Class diagrams: Model new classes and relationships to discover structural business rules – focusing on business objects and rules that must be complied with but are not standard in the industry. (This step may be skipped when the problem is well understood and the rules are standardized.) State-machine diagrams: May be skipped. Activity diagrams: May be skipped.

¹ Agile projects may use ‘user stories’ as an alternative to use cases.

Project Size: Large

Solution type	Lifecycle	UML tools
In-house development	Empirical	Business use cases: Complete (or use a non-UML alternative) in order to capture end-to-end business process workflow. System Use Cases: List and name new use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be worked out through prototyping. Class diagrams: Complete. Classes, relationships and numerical rules (multiplicities) are required for across-the-board business rules. State-machine diagrams: Use to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
In-house development	Definitive	Business use cases: Complete. System Use Cases: Complete Class diagrams: Complete Activity diagrams: Use to describe workflow of business use cases (business processes) and as addendum for system use cases whose flows connect in complex ways.
Off-The-Shelf	Empirical	Business use cases (or a non-UML alternative): For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. State-machine diagrams: Create in order to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
Off-The-Shelf	Definitive	Business use cases: For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. Activity diagrams: Use to describe workflow of business use cases (business processes) focusing on processes that are non-standard in the industry. Use activity diagrams as an addendum for system use cases whose flows connect in complex ways.

Finally, keep in mind that we’re talking here only about the artifacts that are created for each project. Some of these will be directed to business stakeholders and some will only be distributed to other team members and solution providers. But that’s a topic for another column (and one that I address on a tool-by-tool basis in my book, The Business Analyst’s Handbook’).

In the meantime, I’m looking forward to having others weigh in on today’s question “How much analysis do you really need to do?”

Howard Podeswa
For more on this topic, please see The Business Analyst's Handbook and the upcoming release of UML for the IT Business Analyst, 2nd Edition

Top 10 Tech Skills: Process Modeling tops the list

Barton George — Tue, 07 Apr 2009 12:32:00 GMT

Last week I came across an article on NetworkWorld.com that listed today’s “Top 10 Technology skills.” The list was based on work done by Foote Partners, which conducts quarterly assessments of IT pay trends in the US.

Foote Partners’ CEO David Foote says “what’s unique about this downturn is that IT departments are hiring talent in certain areas – such as business process modeling and project management – while laying off in others connected to weak product lines.”

And, indeed, coming in at the top of the list was Business Process Modeling:

1. Business Process Modeling

Business process management, methodology and modeling is one of the few IT niches that saw pay gains in the fourth quarter of 2008, according to the quarterly IT salary survey compiled by Foote Partners. In particular, companies were willing to pay for workers with ITIL IT best practices and CobiT IT governance experience. Pay for these skills was up 10.3% from a year ago and 5.6% from the previous quarter, the Foote report says.

Kevin Faughnan, director of IBM’s Academic Initiative, says business process modeling is one of the key skills that business majors should be studying. “It’s about how does our business work, what are the business processes and how do we analyze them,” Faughnan says, adding that this is a key issue for companies to consider before applying IT to solve business problems.

This seems to make sense to me. It is always important to know your business processes in order to be able to modify and refine them to keep pace with change… and today there is an extra helping of change that we all must not only keep pace with but get ahead of. Business Process Modeling is a key first step.

And the rest…

For the curious, the other 9 skills were:

2. Database
3. Messaging/Communications
4. IT Architecture
5. IT Security
6. Project Management
7. Data Mining
8. Web Development
9. IT Optimization
10. Networking

Barton George
Sr. Director, Business Development, Blueprint process mapping tool
Lombardi Software

Learn about Blueprint and sign up for a 30 day free trial

Why I Do This

Howard Podeswa — Fri, 13 Mar 2009 22:12:00 GMT

I was at a talk yesterday by American artist Lawrence Weiner. He spent half the time saying there was nothing he had to say about his art; the next half saying it. I enjoyed it thoroughly. Something he had to say really stuck with me: that art is all about creating a logical structure for viewing the world. It helped me understand why I make my living doing two things that seem so disparate: visual art (painting) and Business Analysis. There are many things I love about BA but the part I have the most passion for is visual modeling. Perhaps it’s because of what Weiner pointed out: like art, it’s about creating a logical structure that communicates a way of seeing the world (or a part of it). The types of models I am most interested in are referred to as logical models: the name itself gives away the connection to Weiner’s art objects.

I have never been much interested in the physical world – the world of gadgets and mechanical things; it’s always been the logical structures that underlie the real world (RW) that most interest me. What I love about logical visual modeling is that it strips away those pesky physical details to focus on logical structures. It turns out that this is a great boon to the BA. If we focus on physical details there is very little common language between a business person and a software developer. But if we talk model-talk (for example, using a visual language like the UML), well then we can have a nice discussion: we get each other.

I’ve always been attracted to pursuits where you can get complex results but you only have to remember a few basic elements. Maybe it’s because I’ve always had a lousy memory. As a developer, I was a retro fan of Assembler. I’ve never lost my fascination for how its small set of basic instructions could be used to construct the most complex systems. As a BA, I feel the same about the UML diagrams – especially class diagrams. Give me a few basic concepts modeling elements (generalization, association, ...) and I can model the most complex business system. How cool is that?

Howard Podeswa
His most recent book, The Business Analyst's Handbook may be purchased on amazon.ca, and amazon.com.

Could the Recession be Good News for Business Analysts?

Adrian M. — Mon, 09 Mar 2009 05:56:00 GMT

Most of us would agree that recessions are not a good thing – especially the one we are in right now.

But for those daring enough, tough times have can be moments of opportunity.

Many famous companies - such as GE, CNN, HP, Microsoft, Hyatt, FedEx, etc. - started during times of shaky economic conditions.

How did this happen?

They were started by people who recognized a market need and who worked diligently to fill that need. This is the key to starting and building thriving enterprises.

You may not be starting the next Microsoft but there are great opportunities for you, the business analyst, in these tough economic times.

Let’s take a look…

[1] In a down economy businesses tend to refocus on the bottom line: increasing efficiency, reducing costs, and identifying opportunities within the realm of their core competencies. Businesses are now ready to (perhaps forced to) slow down and take a closer look at their Business Architecture as well as employ Enterprise Analysis techniques in order to identify new opportunities.

Who is going to help these organizations with these tasks?

You got it!

It’s YOU, the business analyst…

[2] Many companies, for good or bad reasons, attempt to cut costs by outsourcing and off-shoring new system implementations and software development activities. To enable this, they must employ consultants or employees who understand the business needs/goals and interface with the outsourced providers.

Who do you think is best suited for this task?

You got it again!

It’s YOU, the business analyst…

[3] Have you heard of TARP, Stimulus, or Bailout?

Well – billions of dollars have been set aside to help banks, mortgage, and insurance companies. Attached to these dollars come many new rules, regulations, and conditions. The recipients and hopeful recipients of this money are busy trying to understand and implement the impact of these new rules into their business models, processes, and systems.

Who can benefit from this additional work?

Yep… the Business Systems Analyst, the Process Analyst, the Systems Analyst!

[4] Have you seen the various other changes being proposed though either specific plans or the new proposed budget for rest of 2009:

Numerous tax code changes – do you think the IRS, tax software companies, tax accountants, investment firms, etc. will have to change their models and business software? You bet they will!
Money to Modernize Air Traffic Control Systems – they’ll need top notch systems analysts. Are you one?
Enhance security at Major Ports – this will include many technology projects especially related to security. This might be a good niche for technical Bas who don’t mind learning a thing or two from a Security Analyst.
Align our Education with 21^st Century economic demands – this means science and technology… The might need folks who not only understand technology, know how technology can solve problems, but who can also communicate, teach, and mentor… Many business analysts are great at this!!!
Computerize America’s Health Records & Change the health care system. Do you have healthcare vertical domain knowledge? If you don’t get some, ‘cause this industry could potentially see some of the more drastic changes requiring new processes and business systems. By the way – we have a related free webinar coming: “Visualizing an Electronic Record System: A Case Study for BAs”
Developing and Disseminating Info on Effective Medical Interventions – $1.1 billion dollars have been slated for researching this data. Do you foresee the need for new systems based on solid Enterprise and Data Architecture? I do.
Etc., etc., etc.

It is up to you to identify these opportunities and niches which fit your skills and interests.

By the way – did you notice this month’s eJournal topic: Enterprise Business Analysis & Architecture!

This is the time to look at the big picture and identify trends which could either help or hurt you or your organization.

You mission, should you choose to accept it, is to identify these trends and changes and act appropriately.

This is NOT Mission Impossible… Enterprise Business Analysis is the discipline which will help you do just that.

Any thoughts of what opportunities might be there for you?

Would love to hear your ideas!

- Adrian

Adrian Marchis

Publishing Editor

ModernAnalyst.com

Which Business Analysts are in demand: The Reality!

Adrian M. — Tue, 17 Feb 2009 08:01:00 GMT

I've heard and read many opinions painting the role of the business analysts as being (or needing to be) purely business oriented. The argument is "let the technical team deal with the technical details."

The practice however, the business analyst is confronted by the technical aspects of the solution on virtually every project. These days - it is a rarity, if at all, to find a business project or initiative which does not involve some level of system support.

A recent article in the discussing the state of the Australian job markets commented on the fact that:

"The roles in demand this year will include project managers, architects and business analysts with technical skills."

That has been my observation as well... at least in the USA.

There seem to be very few Business Analyst job postings out there which do not include some level of demand for some technical skills.

Would love you hear your thoughts and comments!

- Adrian

The Business Analyst will probably go down...

Adrian M. — Mon, 09 Feb 2009 08:01:00 GMT

The Business Analyst will probably go down as one of the more important players to help us get out of these terrible economic times.

Now is more important than ever for organizations to improve their processes and squeeze every last bit of productivity out of their business operations. Unfortunately, not all companies will survive - as they try to go at it without thorough business analysis.

Recently I've heard a business executive say something like "last time we've done this type of endeavor things went really bad so this time I'm giving you guys more time". This sounds like a line straight out of a Dilbert cartoon.

Does more time really guarantee success?

Of course not!

Last night I saw all over the news how both Republicans and Democrats battle for the details of the stimulus bill with some saying that getting the bill approved in a timely manner is more important than arguing over the details. Really?

Does spending lots of money (hundreds of billions in this case) guarantee success?

Does acting fast really ensure the desired outcome?

Of course not!

Then what?

Good, solid, and creative Business Analysis!

Our business organizations and our government must make decisions (paralysis is not an option) but they must make the right decisions. Business analysis is the process for analyzing an organization’s problems for the purpose of arriving at effective solutions and effective decisions.

In this month’s eJournal you will:

learn how to use decision management to improve business analysis,
find out how to develop an eye for waste by looking at seven wastes of software development,
discover how to apply creativity in your day to day job, and
hear how to use process mapping to tap into new markets..

And when you’re tired of worrying about your projects – take time off and enjoy some BA Humor.

- Adrian

Adrian Marchis
Editor, ModernAnalyst.com

Possess a Clear Understanding of Business Analysis

Adrian M. — Tue, 27 Jan 2009 07:47:00 GMT

As a programmer who moved into business analysis I got most of my business analysis skills the old fashioned way:

through trial and error,
working on many projects,
stealing from those who succeeded,
learning gotchas from those who failed,
etc.

It was rare when I stumbled upon an experienced consultant who was willing to mentor and who was able to explain the details of the craft.

Chances are, if you want to become a valued business analyst, you will also have to learn the old fashioned way. But, lucky you, there are many resources popping up geared specifically towards business analysts - including books such as:

Seven Steps to Mastering Business Analysis by Barbara A. Carkenord
Getting It Right: Business Requirement Analysis Tools and Techniques by Kathleen B. Hass, Don Wessels, and Kevin Brennan
Professionalizing Business Analysis: Breaking the Cycle of Challenged Projects by Kathleen B. Hass
The Business Analyst's Handbook by Howard Podeswa

I must admit that I'm guilty!

I didn't rush out the door to buy any of these books. I guess I'm still stuck in my old habits of learning by doing.

Having said that, I was lucky enough to get my hand on a copy of Barbara's book Seven Steps to Mastering Business Analysis (thanks to J.Ross Publishing).

I just got through reading the first chapter and...

... I'm impressed (so far)!

The first chapter, Possess a Clear Understanding of Business Analysis, provides a great overview and introduction to our profession.

Through logical explanations and 'case in point' examples, Barbara takes the reader through the basics of understanding the roots, role, and future of the business analyst.

She talks about a number of things such as:

What is Business Analysis? - she mentions:

"Identification of business problems and opportunities"
"Elicitation of needs and constraints from stakeholders"
"Analysis of stakeholder needs to define requirements for a solution"
"Assessment and validation of potential and actual solutions"
"Management of the product or requirements scope"

The Role of the Business Analyst - with good insights into:

Business Analyst traits
History of Business Analysis - I particularly liked this section because it clearly spoke from Barbara's experience on real projects in real organizations.
Where do BAs come from (IT vs. Business)
Where business analysts report

Who Makes a Great Business Analysts - includes:

A list of "the BA must..."
A Business Analyst Suitability Questionnaire
Career progression for the business analyst

Key Business Analysis Concepts - such as:

What is a Requirement?
What is a Project?
What is a Product?
What is a Solution?
What is a Deliverable?

This section also makes a good case for "Why Document Requirements?" which is nice to see in the midst of all the hype about Agile and "documentation is bad" rhetoric. I've worked on enough large scale projects which would have not survived without documentation.

(If you're wondering: I prefer "just enough" documentation!)

So far, the book has proved to be a good an easy read. I'll keep you posted on my thoughts as I progress further in the book.

- Adrian

Demand for Business Analysis skills is still strong

Adrian M. — Tue, 27 Jan 2009 07:03:00 GMT

"The 2009 Benchmark of Salaries and Employment Trends in IT survey from the National Computing Centre says one-third of respondents have experienced a shortage of candidates with certain key skills.

According to the survey, 33.7 percent of organisations highlight problems recruiting or retaining people with Oracle, SAP, .NET, web development, business analysis and network support skills."

- from ZDNet.co.uk

Despite the current economic downturn, finding skilled business analysts is not easy.

My guess is that there are many newcomers to our profession who are trying to get started in a hurry but how don't yet have much experience or formal training. The good and experienced BAs probably already have jobs and are staying put until the economic conditions improve.

For those of you who are new/aspiring analysts - this is a great time to take some time off (if you don't have a job anyway) and get a formal degree or training in business analysis.

- Adrian

Morphis: Accidental Process Consultants

Barton George — Tue, 16 Dec 2008 23:28:00 GMT

Morphis is a company that provides currency supply chain management software and counts among its customers the U.S. Federal reserve as well as central banks, ATMs and armored car companies around the world. Process mapping was the furthest thing from their minds when they started in business but they quickly found out that if they didn’t start leading their customers in process mapping sessions they wouldn’t be able to sell their product.

Last week I chatted with Gary Faulkner of Morphis about how they found themselves unexpectedly leading process mapping sessions for customers or, as Gary likes to describe the turn of events, “A funny thing happened on the way to the software business.”

Take a listen:

>> My talk with Gary (6:59): Listen (mp3) Listen (ogg)

Process mapping enabled a pair-o-dime shift for this currency manager. (sources: my fingers and my dimes)

Some of the Topics we tackle:

Conundrum: Morphis is meant to be customized to fit a customer’s process but if a customer can’t describe their process how can Morphis be customized?
Being new to process mapping they were looking for something that was intuitive and easy to use.
The power of seeing the process laid out visually and the importance of working on the excercise collaboratively.
How Morphis’s implementations are all done virtually over Webex around the globe

Barton George
Sr. Director, Business Development, Blueprint
Lombardi Software

BA 2.0

lwoods — Sun, 07 Sep 2008 04:44:00 GMT

“Web 2.0” allows increasingly collaborative work among teams of varying roles, locales and technical abilities and facilitates the move toward the business user as "user-innovator" a la Eric von Hippel. User expectations are shaped by their experiences on the web and they demand and can manage increased control and participation in both the development and use of technologies. With the BA profession already in flux (consider the recent development of the IIBA certification...and the debate over the difference between a BA and PM) the implications of Web 2.0 for the business of Business Analysis are daunting:

Mobs rule! More (people) is better. That is, instead of benefiting from a small controlled group of users, Web 2.0 products and projects evolve and improve in relation to the number of people who use, refine and provide feedback on them. In the collaborative 2.0 arena, a small disciplined group doesn’t provide the biggest payoff…BAs must refine their crowd-control skills to facilitate and encourage the participation of unruly groups, and must be agile (capital and lowercase A) in the ways they present and refine prototypes.

You say “Bull in a china shop” like that’s a bad thing; users are less, not more predictable. The “paths” of users in collaborative, customizable, scalable applications don’t boil down neatly to a set of happy and alternate paths. The typical use case becomes a sidetracking waste of time in the face of apparently infinite (legitimate!) trajectories of a Web 2.0 user “through” a system. BAs must become adept at recognizing, zeroing in on and evaluating patterns of user behavior and must develop and manage new ways to capture and model these patterns. A pattern rather than transaction perspective mandates the ability to think and to communicate at a more abstract level than Control/Action/Response; under this paradigm, that BA staple, the use case, evolves to look more like a mind map of loosely-coupled services, and no longer fits neatly into tables or even action/response narratives.

Yours, mine, ours? Data is king (but what’s the kingdom?) The ability to manage data can be the defining factor in the success or failure of a 2.0 venture. BAs must increasingly be able to identify, model and locate in-play data, and to differentiate between actual versus customary restrictions on data. Most crucially, BAs must help to maximize ROI by identifying and advocating for the control and harvesting of core data, while promoting the licensed acquisition/use of non-key data.

Reduce, reuse, recycle. Web 2.0 relies on the flexibility of loosely-coupled systems which can be reconfigured and reused to empower users. BAs must propagate and reinforce this mindset by promoting and demonstrating new ways to assemble existing services and by facilitating the churn. In addition, BAs must promote practices that are device agnostic; promote the awareness and consideration of multiple platforms and interfaces, and capture business rules in a manner that allows them to be applied over

Web 2.0 is in the eye of the beholder. There’s no concise definition of Web 2.0; it’s as much a philosophy or set of principles as anything else. What is clear is that in the light of the agility, speed, user involvement and collaboration that the Web 2.0 gestalt imposes, BAs will increasingly need strategies to ensure that minimum regulatory and policy requirements are met even when the affiliated documentation is of no value to the project as a whole; over time this burden (creating artifacts that are actually separate from the “real” development activities) will likely be offloaded to other roles, and the Business Analysis role itself will split into collaborative-track versus “traditional” analysts.

(Originally posted at catsandlassos.com)

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 1

ModernAnalyst.com — Sun, 25 May 2008 14:40:00 GMT

Have you ever had to use a map to get somewhere, and after navigating around the wilderness for hours, eventually had to ask for directions because it failed you?

Alternatively, have you ever read directions to assemble a toy, and rather than help you, the directions made things much more complicated?Perhaps you just figured it out on your own, without the directions.

This is what some BA’s and IT folks do all the time. They get understandable Business Requirements in hand, the bugle sounds, and IT is immediately restless in the starting gate. And they are off!Who will be the first IT hero to come up with a solution or the code which business will say yes!

In this kind of a race, there is never a finish line.The race will go on forever until all of the problems are solved; and in fact some of the problems are the results of other solutions. Finally, someone in IT draws a white line in the sand (creates a functional Design Document or something) and says to the business, 'is this ok?'If the business agrees, then the race is over. Now it's time for the next game.

Now we play a game of tag.The IT group starts coding the solution. After a while, an issue comes up and the IT folks tag a businessperson.“You're it”, say the IT folks. “When you have an answer, let us know.” (Back to Doom 10)

The businessperson comes back with an answer, and now the IT folks are tagged.This goes on until all of IT‘s questions are answered, or the business gets frustrated to a point and says, “Just do something.” As a result, someone in IT or the business erases the white line from the first game, and redraws the white line somewhere else.

Now if you’re lucky, the BA is so annoyed by this, that they says to IT, “Let's just get more precise requirements.The IT folks say no way. The business is already ticked off, and talking to them again will only tick them off more.We cannot start over, we must use what we have, and you need to sell it to them (or shove it down their throat) and make them like it. Speak their language; and it should be easy.

Therefore, the BA starts selling the solution (after finishing up his/her resume).This is where 'Do you feel lucky' comes in to play. We all know what happens from there.A two month project takes 1 ½ years and costs $1.5 million dollars and a death march.

The examples above are about being precise and understandability. Jonathan Babcock wrote a great article in his blog titled Good Requirements Are More Than Just Accurate. This is a great article; take the time to read it.

Now, since I got out all of my pent up aggression, I need a week to recover. Next week, in part 2 we will look at how we get precise and understandable requirements, and stop the games above.

By the way, I really do like IT folks. It's just that sometimes I don't like the way they do things.Ok, sometimes I hate the way they do things. In most cases, though, the IT folks are just trying to help the business, and that honorable intention is what gets us all in trouble some times...

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 2

Wed, 02 Apr 2008 04:56:00 GMT

In Part 1, we learned that the less precise things are, the easier it is to understand them. Thus the paradox: how do you get precise requirements and easy to understand requirements?

According to the requirements gods and goddesses, there are fundamentally three levels of requirements ( you can break these down into more but that is another blog):

1. Business Requirements- Why the project is being undertaken;
2. User Requirements- What users will be able to do with the product;
3. Software Requirements – What the developers need to build.

Take a look at the statements below:

Business Requirements are the easiest to understand, but the least precise;
User Requirements are more difficult to understand, however they are more precise than the Business Requirements;
Software Requirements are even more difficult to understand, yet they are the most precise.

The more perspectives you include, the more precise things get, and the less understandable things become. When we can no longer recognize where we are, we get lost and do not understand how we got there.

When we were kids, and our parents would drive us to the market to go grocery shopping, (sometimes three or more times a week since we would forget stuff) we learned how to get to the grocery store. For us, this was a good 15-20 miles away. However, after a period of time, we knew how to get there in at least two different ways: Dad’s way, and Mom’s way. Still later, we learned the way Grandpa and Grandma went to the store; now we know three ways.

One day Mom and I were on the way to the grocery store, and there was road construction. As we were waiting in the long line of backed up cars, I recognized the street Dad takes to the grocery store. I told Mom that we could get to the grocery store faster if we took Oak Street, and then State Street (I wanted my baseball cards, and my money was burning a hole in my pocket, like you would not believe). Mom looked over at me, very surprised, and said, “Good idea!” Off we went, thus now a 4th way to get to the grocery store. The key to solving our unexpected dilemma was that we had been to the store repeatedly, in different ways, opening up our options in a time of crisis.

As a good BA, we should facilitate the business and IT through each of the requirement levels by showing repeatedly how we arrived there through tractability.

Thus, developing a map on how to get from an easy understandable business requirements to user requirements, and ultimately to software requirements. People have a better chance of understanding with a map and if they do not, they should ask for a better map from the BA.

The BA acts like a tour guide (a facilitator, not a leader or manager) through the maze of requirement levels. The BA should be guiding the Business and IT team through the requirements collaboratively, and allow the groups to discover the map on their own through the process.

If you discover something through a process, you will understand it much deeper than if someone just told you.

Requirements elicitation is a gathering process, and a learning process.

If you do one without the other, you will play the “Do You Feel Lucky, Punk” Game in Part 1. So as you transition between each type of requirement, work through the transition collaboratively, in a facilitated process.

So, do you feel lucky?

The Dirty Harry Approach to Requirements, or “Are you Feeling Lucky, Punk?” Solve Problems First, Ask Questions Later - Part 1

Thu, 20 Mar 2008 05:03:00 GMT

Have you ever had to use a map to get somewhere, and after navigating around the wilderness for hours, eventually had to ask for directions because it failed you?

Alternatively, have you ever read directions to assemble a toy, and rather than help you, the directions made things much more complicated? Perhaps you just figured it out on your own, without the directions.

This is what some BA’s and IT folks do all the time. They get understandable Business Requirements in hand, the bugle sounds, and IT is immediately restless in the starting gate. And they are off! Who will be the first IT hero to come up with a solution or the code which business will say yes!

In this kind of a race, there is never a finish line. The race will go on forever until all of the problems are solved; and in fact some of the problems are the results of other solutions. Finally, someone in IT draws a white line in the sand (creates a functional Design Document or something) and says to the business, 'is this ok?' If the business agrees, then the race is over. Now it's time for the next game.

Now we play a game of tag. The IT group starts coding the solution. After a while, an issue comes up and the IT folks tag a businessperson. “You're it”, say the IT folks. “When you have an answer, let us know.” (Back to Doom 10)

The businessperson comes back with an answer, and now the IT folks are tagged. This goes on until all of IT‘s questions are answered, or the business gets frustrated to a point and says, “Just do something.” As a result, someone in IT or the business erases the white line from the first game, and redraws the white line somewhere else.

Now if you’re lucky, the BA is so annoyed by this, that they says to IT, “Let's just get more precise requirements. The IT folks say no way. The business is already ticked off, and talking to them again will only tick them off more. We cannot start over, we must use what we have, and you need to sell it to them (or shove it down their throat) and make them like it. Speak their language; and it should be easy.

Therefore, the BA starts selling the solution (after finishing up his/her resume). This is where 'Do you feel lucky' comes in to play. We all know what happens from there. A two month project takes 1 ½ years and costs $1.5 million dollars and a death march.

Now, since I got out all of my pent up aggression, I need a week to recover. Next time we will look at how we get precise and understandable requirements, and stop the games above.

By the way, I really do like IT folks. It's just that sometimes I don't like the way they do things. Ok, sometimes I hate the way they do things. In most cases, though, the IT folks are just trying to help the business, and that honorable intention is what gets us all in trouble some times.

Continuing a project in the penumbra...

enavarro — Tue, 27 Nov 2007 04:14:00 GMT

INTRODUCTION

Being dropped in the middle of a project that is already in a bad shape (over budget, over schedule and under compliance) is not easy (or funny). So try to make the best of it and get out of it alive.

On most cases, you get a project start with the business case or whatnot, then continue on with a chain of events. On most of my encounters I have dealt with projects already started and left in the Bermuda Triangle to drift or where the end was reached with no particular direction. The usual case of this type of situations comes from the mind-set of the culture the individuals are involved in. Regardless, you will have about no time for testing, little time for development and the who cares attitude. Not to mention you dont want to look stupid in front of the client going over to them and asking the questions that should've been asked beforehand.

Well this has been my case for the past 2 projects, they were already started, got derailed, no documentation whatsoever and an ever-present pressure to finish off because its already over budget. I can tell you now its not an easy task to come in SWAT Teamstyle and continue a project. So I made it... twice... with relative success, here are a few pointers.

THE TIPS

Tip#1: Focus on goals and measurable outcomes not on reconstructing whatever happened

I met some friends who make extensive use of CIMOSA, which is a simple yet effective approach. I borrowed some of their knowledge, and decided to focus on the KPI's and CSF's (see Definitions section), that is derail from the temptation of reconstructing the past design and unmade documentation from virtually zero requirements documentation or whatsoever.

Tip #2: Make sure that you get your project manager in check with the tasks

I noticed that even if the requirements documentation was bad, dissecting the requirements into an Excel spreadsheet and then assigning the project tasks that related to that specific requirement worked wonders with only a 4 to 16 hour effort (time is porportional to size). So you can actually give intelligent feedback to the PM and focus on the result: compliance to contract.

Tip #3: As cruel as it sounds, stick to the contract

Yes, I HATE mediocre work, poor solution design and giving the client something I know that doesn't solve their pains. Yet, in all honesty, you are not going to solve that organizations problems in a week, or 2. It will take some extensive work that was previously undone and HAS to be performed in order to really attack the root causes of problems, otherwise, you can and will possibly transfer the problems from functional organizational unit, or make it worse. So make sure to meet contracted demands in due time.

Tip #4: Dont forget to write it though

Even if you cant solve all of an organizations problems and need to focus on the task at hand, make sure to write all this stuff up. Bring it up at an internal status meeting and make sure your sales people get a hold of this information. If you can forsee substantial business improvement within your client's operation, he will appreciate you taking the initiative and bringing up intelligent assessments (and possible HR investment from your company to further analyze this and make a business case).

DEFINITIONS

KPI = Key Performance Indicator - measurable outcomes of a specific process that can tell you if you are headed in the right direction

CSF = Critical Success Factors - business goals that have to be met in order to comply with the business needs

Obstacle Analysis: How Problematic Scenarios Occurring during Requirements Analysis can be Nullified

Wed, 24 Oct 2007 03:46:00 GMT

Analysts everyday and in every domain of business come across obstacles in their analysis and efforts that prevent them from best meeting the needs of the business. These obstacles can be in the form of business processes, or system limitations, or both. Furthermore, a considerably big obstacle can be potentially detrimental to the spirit and purpose of a project. Obstacle Analysis is a tool that provides a systematic approach to overcoming those obstacles. Tackling road-blocks carefully and comprehensively can aid in achieving the mission of a project and in turn, satisfy customers.

I recently came across a research paper that revolved around the topic of Obstacle Analysis. The tool was applied to identify contingency requirements governing the mechanism of an unpiloted lightweight, experimental aircraft. Unsurprisingly soon after reading the paper I was under the impression that Obstacle Analysis was used mainly for increasingly autonomous, goal-oriented applications where safety was paramount. By “safety” I mean if one is going to build a flying, unmanned aircraft, you also want to build in autonomous safety features that would otherwise be handled by humans to prevent the vehicle from flying toward a collision. Besides, I don’t think there many on this portal, yet, who engineer requirements for real-time and embedded systems or tangible, moving objects.

Fortunately, I also quickly realized that Obstacle Analysis could be useful in conventional, (object-oriented) software requirements engineering aimed for desktop applications that we all work with daily. Hence, I feel confident in writing this entry expecting that it will be of use to other fellow analysts. I read the paper, read it once more, highlighted the main points, and promptly applied the tool to one of my smaller and uncomplicated projects to start with. You might notice that it's main usage comes in the requirements analysis phase.

So without any further ado, what exactly is Obstacle Analysis? Many of us may have already used it unwittingly in some informal way or another. In my own words, and to not plagiarize the paper, Obstacle Analysis is a systematic approach to identifying, analyzing and neutralizing obstacles that hinder the accomplishment of a necessary goal.

The following is an explanation of the steps involved:

IDENTIFY THE SUB-GOAL (the paper calls this Goal, but for semantics purposes, I prefer to use of the term "Sub-goal")

What is the goal that for which you as an analyst are engineering requirements? This, most likely, is a sub-goal that when executed correctly will lead to the achievement of a bigger goal. What is a goal anyway? A goal is one or a set of results expected to materialize on successful execution of one or more tasks.

IDENTIFY THE AGENTS

Agents are participants who will implement or aid in the implementation of the sub-goals. This could software components, hardware objects, and humans. This is an important element of the analysis, in that identifying the agent itself might resolve the obstacle.

IDENTIFY THE OBSTACLES

If a goal is a behavior of the system that is desired, an obstacle is an element that keeps that goal from being accomplished. What is it that prevents the goal from being achieved? This is step is particularly cyclical in rational thought – a decent understanding of the application being built will aid in uncovering its weak points that might need attention. Tackling the weak points and making the system more robust, in turn, only deepens one’s understanding further…and the cycle continues.

IDENTIFY ALTERNATIVES TO THE OBSTACLE

It is here that we offer multiple solutions to eradicate the obstacle. It is imperative that we list as many solutions as possible since, the next step depends on this one. There are multiple ways to identify alternatives:

De-scope the goal itself. At first, this may sound brash. But on closer thought, we realize that it’s not uncommon to simply wipe the goal off the slate and shrink the scope. Resolving the obstacle may pose a budgetary or scheduling challenge which a team might not be willing to undertake. Hence, getting rid of the goal might actually be a viable option.
Assign a Different Agent so that someone or some other component of the system helps in accomplishing the goal without giving rise to the obstacle.
Add a New Goal to the existing one if it prevents the obstacle from arising again.
Modify the Goal in that the obstacle will not arise in accomplishing the new goal.
Change the Domain in a way that the goal simply does not occur and keeps the goal in tact.

SELECT AN ALTERNATIVE

Choose the option that will best tackle the obstacle and thus, aid in achieving the goal.

In conclusion, I believe this is a comprehensive tool to tackle obstacles that we as analysts face nearly everyday. One of the obstacles that I tackled for my project using this tool resulted in nullifying the malicious effects of the obstacle, remaining within the scope, accurately meeting the main goals of the business, and a cleaner, less-complicated code from development.

For your curiosity, the paper can be accessed from here. Thanks in advance for your thoughts, comments and corrections, if you see any, for others to gain from. I also thank Lutz, Patterson-Hine, Nelson, Frost, Tal, and Harris (2006) for their research.

A framework for defining competencies for business systems analysts

Adrian M. — Mon, 09 Jul 2007 02:48:00 GMT

If you are managing business or systems analysts, trying to identify the skills and competencies required of your analysts is not an easy task. The expectations placed upon the analyst vary widely from organization to organization. The variations are so drastic that the actual title doesn’t not say much about the type of work your analysts do.

I have interviewed business analysts who have only worked on the business side and were never involved in the creation or modification of a system. On the other hand, I have met business analysts whose only responsibility was to create functional specifications.

OK… so what does this mean?

First, let me say this: “It’s not what you’re called, it’s what you do!”

What this means is that you should not try to figure out the skills and competencies of an analyst by their title – you need to know exactly what types of tasks you are expecting your analysts to perform.

In order to do that I like to put some structure around this topic to help you discover the skills and competencies expected of your analysts.

Let’s try!

- The Analyst bridges the gap between business & technology.

- The analyst plays a number of roles.

- To perform each role, the analyst draws knowledge from a set of disciplines.

- Each discipline defines a set of activities which the analyst performs.

- Each activity takes inputs and produces outputs.

- Each activity requires a given set of competencies.

- These competencies may include analytical, business, and technical skills.

Simple Definitions:

Analyst = this refers to the person whose title is generally business analyst or systems analyst but may have titles as diverse as: IT Business Analyst, Requirements Engineer, Computer Analyst, Functional Analyst, etc.

Role = The role refers to the analysts’ expected function in a given project or team. It speaks to the behaviors, rights, and responsibilities that are expected from the analyst in a given context. This is where we often get in trouble as the role of the analysts changes from project to project and task to task. Many analysts have what is known as “role confusion” in the situations when he/she has trouble figuring out exactly the role(s) they are supposed to play.

Discipline = A discipline represents a branch of knowledge (part of a larger body of learning) which defines a set of activities to be performed as well as the competencies needed to perform the given activity. For example, “testing” is a discipline which defines a set of activities and competencies needed by a QA analyst while testing software,

Activity = An activity represents a task or effort that is expected to be performed by the analyst in the context of a given role. Each activity must be clearly defined as is usually represented as having: a purpose (why perform the activity), outcome (what are the results/artifacts of the activity), and a method (how to perform the activity).

Competency = In general, competency refers to one’s ability (qualification and capability) to perform a given activity. In the case of the analyst, this requires an appropriate mix of knowledge (theoretical understanding), skills (practiced ability) and attitudes (way of thinking and opinions).

At a high level, I like to categorize the competencies needed by business analysts and systems analysts as follows:

Analytical competencies – because first and foremost, the analyst is supposed to “analyze” – obvious but often overlooked by many organizations.
Business competencies – because the analyst is expected to understand and solve business problems.
Technical competencies - because, in many cases, business problems are solved using technical solutions (information systems).

Any thoughts? Would love to hear your feedback!

Tablet UML

Adrian M. — Thu, 05 Jul 2007 02:41:00 GMT

In most of the projects and organizations I have worked for I have seen a very interesting pattern:

- Developers get developer specific tools such as MS Visual Studio.

- Testers get testing specific tools such as Mercury TestDirector.

- Analysts get MS Word, Excel, and PowerPoint. The more "progressive" organizations might provide their business analysts and systems analysts with Visio.

Wow... cool!

If you think I'm venting, you right? I am venting!

To tell you the truth: I don't get it!

There are so many great tools for requirements management and system modeling yet most organizations have not yet realized that spending a few bucks on tools for their analysts can actually improve productivity and save them money in the long run.

My gut feeling tells me that this problem is closely tied to the view of the business analyst. The business analysis, as a profession, it's just beginning to bud.

I'm hoping that, soon, most organizations will begin to realize the value that business analysts and systems analysts bring to the table. When that happens, the shortage of qualified analysts will be evident and companies will try to find other ways to increase productivity. An adequate tool is one such way!

But I digress...

What triggered these thoughts (again) was that I stumbled upon a UML tool for the Tablet PC called Tablet UML. While I have not used the product - it's a very intriguing idea. Imagine being in a JAD session or brainstorming meeting and, instead of pen & paper, using a tablet PC to capture the models being discussed.

Technologies and tools such as these are going to become more and more important and valuable as organizations realize the importance of analysts and attempt to find new ways to increase their productivity.

More on how to deal with bad requirements

Adrian M. — Sun, 24 Jun 2007 02:26:00 GMT

After posting my last entry on questioning suspect requirements, I've read a great piece on the SlickEdit blog titled "How to Design Software With Bad Requirements."

Scott offers some practical tips to help developers deal with bad requirements. These also apply very well to business analysts and systems analysts:

come up with good use cases - to help the business user visualize the system or process scenarios which do not make sense,
create a prototype - if the end user's request can be modeled using a UI prototype, do so - they may see the light,
abstract and encapsulate - assume that these requirements will change eventually and design your system in such a way to be able to easily modify it in the future,
don't get discouraged - keep your spirits up and make the best out of the situation.

Systems Analyst in the list of Best Careers 2007

Adrian M. — Sun, 24 Jun 2007 02:03:00 GMT

The Systems Analyst role is and will continue to be one of the best careers for a long time.

In their “Best Careers 2007” report, US News and World Report lists 25 professions that will continue to grow in demand.

With the advent of outsourcing, it is not surprising that the software engineer or web developer professions are NOT on the list...

...however, systems analyst is.

One of the most interesting quotes form this report is that the systems analyst "is among the most offshore-resistant computer-related careers".

Another interesting observation is that the majority of the 25 careers are high-touch/social occupations. In the US, we continue to see a trend of increased demand for careers which requires social interaction skills. Business Systems Analyst is one of them.

A couple more items of from the report about the Systems Analyst:

Median pay: $70,438
Job Market outlook: A
Attainability: A
Quality of Life: B
Prestige: B

If you are contemplating starting your career as a systems analyst you might also find the following resources useful:

A Day in the Life of a Systems Analyst

Computer Systems Analyst profile (U.S. Department of Labor)

Systems Analyst Community

Systems Analyst Resources

Salary Info for Business Systems Analysts